The possibility of identifying the geographic location of users in cellular wireless communication networks has enabled a large variety of commercial and non-commercial services, e.g., navigation assistance, social networking, location-aware advertising, emergency calls, and the like. Different services may have different positioning accuracy requirements imposed by the application. In addition, some regulatory requirements on the positioning accuracy for basic emergency services exist in some countries, i.e., FCC E911 in the USA.
The accuracy of the provided result, as well as the response time, depend on a number of factors, such as terminal capability, network capability, requested quality of service (QoS), positioning methods availability, and the positioning method selection procedure employed. The following positioning technologies are currently being considered for the Long Term Evolution (LTE) cellular system: Assisted Global Navigation Satellite System (A-GNSS), Time Difference of Arrival (TDOA), Fingerprinting, Angle of Arrival (AoA), Enhanced Cell ID (E-CID), Cell ID (CID), and Hybrid positioning. The variety of the standardized methods is explained not only by the range of applications and location services (LCS), but also by their environment- and deployment-dependent performance. In challenging environments, different methods may also complement each other to achieve the desired accuracy, e.g., by being hybridized. It has also been shown that using various types of measurements and positioning-related information can enhance positioning performance significantly, which is exploited, for example, in the Adaptive E-CID (AECID) positioning method.
The input to the positioning function, which performs the actual positioning of a specific target node, e.g., User Equipment (UE) or radio node, is a positioning request from an LCS Client with a set of parameters, such as QoS requirements. The end results of the positioning function are the location information for the positioned target node, communicated as a part of the positioning response. An LCS client is a software and/or hardware entity which may or may not reside in the target node being positioned. The LCS client may be internal or external to the Public Land Mobile Network (PLMN).
The location information may be requested by, and reported to, an LCS Client associated with a UE or radio node, or by an LCS Client within or attached to the Core Network. The location information may also be utilized internally in the system; for example, for location-assisted handover or to support other features, such as home location billing. The location information request may ask for the velocity of a UE as part of the positioning information.
The target nodes may have different characteristics and thus may have different capabilities which may impact the amount and the contents of any downloaded assistance information, the set of feasible reporting formats, and the positioning method selection. The target node capability may be signaled together with the positioning request or may be requested later by the positioning server, prior to calling the positioning function. To inform the target node of network capabilities, e.g., the set of available positioning methods, the network capability information may also be communicated to the target node.
In 3GPP or 3GPP2 networks, there is no concept of using civic address information in any way for positioning purposes. As used herein, the terms “civic address information” and position information in a “civic address format” means location information expressed in textual fields commonly used in civic life to communicate address or location information, such as street name and number, city, state, postal code, and the like. In contrast, as used herein, the term “3GPP positioning format” refers to any of the positioning formats defined in the 3GPP Technical Specification TS 23.032, “Universal Geographical Area Description (GAD).” These positioning formats are defined for LCS in wireless communication networks. 3GPP positioning formats include, e.g., a polygon; an ellipsoid arc; an ellipsoid point; an ellipsoid point with uncertainty circle; an ellipsoid point with uncertainty ellipse; an ellipsoid point with altitude; and an ellipsoid point with altitude and uncertainty ellipsoid; as described in greater detail herein.
An attempt to utilize civic address information in connection with location is being made in non-3GPP IP access networks within the Internet Engineering Task Force (IETF) community (see, e.g., Requirements for Emergency Context Resolution with Internet Technologies, RFC 5012, January 2008, the disclosure of which is incorporated herein by reference in its entirety). In these applications, the location information is used by emergency call routing entities to route emergency calls to the appropriate Public Safety Answer Point (PSAP) with the minimum delay. The location information comprises either the civic address or (longitude, latitude, [altitude]) information. The location information can be entered by the user or it can be acquired by the user/UE from the access network or a proxy over the Internet Protocol (IP) layer. The location-to-PSAP mapping functionality maps the location to the Uniform Resource Identifier (URI) of the PSAP. This is primarily intended for emergency calls and IP Multimedia Subsystem (IMS) networks, and all of the functions are performed over IP. However, these efforts do not interwork with 3GPP/3GPP2 networks, and will not provide location information for such a request.
FIG. 1 depicts the general arrangement of the Location Service (LCS) feature in a 3GPP network comprising GSM, UMTS and LTE where the LCS entities within the Radio Access Network (RAN) communicate with the Core Network (CN) across the A, Gb, Iu and S1 interfaces. Communication among the RAN LCS entities makes use of the messaging and signaling capabilities of the RAN. As part of their service or operation, the LCS Clients may request the location information of UE. The clients make their requests to a LCS Server. There may be more than one LCS Client and more than one LCS Server. The client must be authenticated and the resources of the network must be coordinated including the UE and the calculation functions, to estimate the location and optionally, velocity of the UE, and the result returned to the client. As part of this process, information from other systems (other RANs) can be used.
FIG. 2 shows the general arrangement of the Location Service (LCS) feature in an Interworking WLAN (I-WLAN), illustrating the relation of LCS Clients and servers in the core network with the WLAN Access Networks (e.g., IEEE 802.11). The LCS La interface is added to support LCS for I-WLAN.
The exact positioning procedure flow depends on the origin of the positioning request. In 3GPP networks, the following types of positioning, or location, requests (LRs) exist: Network-induced LR (NI-LR); Mobile-terminated LR (MT-LR); and Mobile originating LR (MO-LR). MO-LR is the capability of the mobile station to obtain its own geographical location, or have its own geographic location transferred to another LCS client.
Positioning architecture and some positioning procedures are described herein, for illustration and not limitation, for LTE. Many parts of the description are similar for all 3GPP networks.
The positioning flow for NI-LR, MT-LR and MO-LR defined for GSM, UMTS and LTE networks are depicted in FIGS. 3, 4 and 5, respectively. For further detail, see 3GPP Technical Specification 23.271, “Functional stage 2 description of Location Services (LCS),” V 9.2.0, December 2009, the disclosure of which is incorporated herein by reference in its entirety. The positioning flow defined in connection with emergency calls (e.g., in FIG. 3) may have a slightly different flow than in a general case for the same request type.
FIG. 3 illustrates the NI-LR procedure used to position a UE at the beginning of an emergency call. The (Visited) Mobile Switching Center (VMSC/MSC) server in the core network will detect an emergency services flag set by the UE and forwarded by the RAN. The VMSC/MSC server will then send a positioning request to the RAN with a specified Quality of Service. The RAN acts upon the request and passes the results back to the VMSC/MSC sever. The VMSC/MSC server will forward the UE position information to the Gateway Mobile Location Center (GMLC). The GMLC will signal the UE position to the LCS client which is the Emergency Center or Public Safety Answer Point (PSAP).
FIG. 4 illustrates the MT-LR procedure used by a Client to locate a UE during a call. The Client sends a positioning request to the GMLC. The GMLC will check with the HLR to verify if location services are allowed for the specific UE and if so, to obtain the address of the serving MSC/SGSN/MME. The GMLC will then send a positioning request to the serving MSC/SGSN/MME. The serving MSC/SGSN/MME forwards the positioning request to the serving RAN. The RAN responds to the serving MSC/SGSN/MME with the UE position. The serving MSC/SGSN/MME forwards the UE position to the GMLC. The GMLC forwards the UE position to the requesting Client.
FIG. 5 illustrates the MO-LR procedure used by a Client to request its own location from the network. The UE sends a service request through the RAN that is recognized by the serving SGSN/MME. The serving SGSN/MME sends a positioning request to the RAN. The RAN responds to the serving SGSN/MME with the UE position. The serving SGSN/MME forwards the UE position to the UE and optionally, to an LCS Client that was specified in the UE's service request.
FIG. 6 shows the architecture for positioning of a UE with E-UTRAN access, where E-SMLC and SLP are the control-plane positioning node and the SUPL entity responsible for positioning over the user plane, respectively. In FIG. 6, the positioning session is always invoked by the MME, which may either decide to initiate some location service on behalf of a particular target UE (e.g., for an IMS emergency call from the UE), or may receive a request from another entity, such as: the UE at the NAS level; some entity in the EPC (e.g. GMLC); or a radio node (e.g., eNodeB). Two positioning protocols are defined for positioning procedures in E-UTRAN: the LTE Positioning Protocol (LPP) and the LPP Annex (LPPa).
LPP is a point-to-point protocol used between a location server and a target device in order to position the target device using position-related measurements obtained by one or more reference sources. For LPP messages, a server could, for example, be an E-SMLC in the control plane or an SLP in the user-plane, while a target could be a UE or SET in the control and user planes, respectively. LPP uses RRC as a transport over the Uu interface between the UE and the E-SMLC, S1AP over S1 and the SLs interface between the eNodeB and the eSMLC. The following transactions have been specified for LPP: capability transfer procedure (request/provide messages); assistance data transfer procedure (request/provide messages); and location information transfer (request/provide messages).
The LTE Positioning Protocol Annex (LPPa) is a protocol between the eNodeB and the E-SMLC which conducts the LPPa Location Information Transfer procedures for positioning-related information and LPPa Management procedures not specifically related to LCS.
Signaling service between E-UTRAN and EPC is provided over the S1 interface by means of the S1 Application Protocol (S1AP). The S1 interface between the eNodeB and the MME is called S1-MME and is utilized in control-plane positioning solutions (see FIG. 6). The SLs interface is standardized between the MME and the eSMLC with the LCS-AP protocol operating over the interface. The S1 interface between the eNodeB and the Serving GW is called S1-U and it is utilized in user-plane positioning solutions (not shown in FIG. 6).
The 3GPP specification TS 36.413, V 9.0.0, “Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)”. September 2009, the disclosure of which is incorporated herein by reference in its entirety, defines the following location-related procedures for S1AP:
Location Reporting Control, which allows the MME to request the eNodeB to report the current UE location, with the message LOCATION REPORTING CONTROL;
Location Report, by which the eNodeB provides the UE's current location to the MME by using the message LOCATION REPORT; and
Location Report Failure Indication, by which the eNodeB informs the MME that a Location Reporting Control procedure has failed, with the message LOCATION REPORT FAILURE INDICATION.
The positioning result, i.e., the estimated position, is reported back to the entity which generated the positioning request (e.g., UE, BS, etc.). In the prior art solutions, the position is reported following one of the seven shapes defined in 3GPP specification TS 23.032, “Universal Geographical Area Description (GAD),” the disclosure of which is incorporated herein by reference in its entirety. These formats, referred to herein as “3GPP positioning formats,” are common for all 3GPP/3GPP2-compliant networks (e.g., GSM, UMTS, and LTE). The particular format used depends on the positioning method and on the reporting capabilities at the receiving end. The reporting formats are explained in greater detail below.
Methods for converting between the 3GPP positioning formats have also been proposed, for example, by T. Wigren, M. Anderson, and A. Kangas, in the paper, “Emergency call delivery standards impair cellular positioning accuracy,” published in the Proceeding of IEEE ICC 2010, Cape Town, South Africa, May, 2010, the disclosure of which is incorporated herein by reference in its entirety. One of the reasons for the format conversion is the fact that the standards used in the USA for emergency call delivery support only the ellipsoid point with uncertainty circle format when delivering the calculated position to the Public Safety Answer Point (PSAP).
In cdma2000, the location is reported following the WGS-84 reference ellipsoid format—an ellipsoid point, optionally with uncertainty circle or uncertainty ellipse, associated with one of the pre-defined confidence levels. The WGS-84 is also the reporting format for IEEE 802.x wireless networks (e.g., 802.11 or 802.16).
Polygon: the polygon format is described by a list of 3-15 latitude, longitude corners, encoded in WGS 84 coordinates. The polygon format does not carry confidence information, the confidence being defined as the probability that the positioned entity is actually located in the reported geographical region. This format may be obtained by application of cell ID positioning in LTE.
Ellipsoid arc: The ellipsoid arc is described by a center point (eNodeB antenna position), encoded as latitude, longitude in WGS 84 coordinates. Furthermore, the format contains an inner radius of an arc, a thickness of the arc, as well as the offset angle (clockwise from north) and the included angle (opening angle). Together, these parameters define a circular sector, with a thickness and with left and right angles. The ellipsoid arc does carry confidence information. This format is, for example, produced by cell ID+TA positioning in LTE.
Ellipsoid point: the ellipsoid point format is described by a center point, encoded as latitude, longitude in WGS 84 coordinates. The format neither carries uncertainty, nor confidence information.
Ellipsoid point with uncertainty circle: The ellipsoid point with uncertainty circle format consists of a center point, encoded as latitude, longitude in WGS-84 coordinates, in combination with a radial uncertainty radius. The format does not carry confidence information.
Ellipsoid point with uncertainty ellipse: The ellipsoid point with uncertainty ellipse format consists of a center point, encoded as latitude, longitude in WGS-84 coordinates. The uncertainty ellipse is encoded as a semi-major axis, a semi-minor axis, and an angle relative to north, counted clockwise from the semi-major axis. The format carries confidence information. This format is typically produced by OTDOA and A-GPS positioning in LTE.
Ellipsoid point with altitude: The ellipsoid point with altitude format is encoded as an ellipsoid point, together with an encoded altitude. The format neither carries uncertainty, nor confidence information.
Ellipsoid point with altitude and uncertainty ellipsoid: This is the format commonly received from A-GPS capable terminals. It consists of an ellipsoid point with altitude and an uncertainty ellipsoid, the latter encoded with a semi-major axis, a semi-minor axis, an angle relative to north, counted clockwise from the semi-major axis, together with an uncertainty altitude. The format carries confidence information.
With the exception, described above, of attempts by IETF to allow for using the civic address information in connection to emergency call routing, civic address information in conventional networks is not used for positioning and location services. In particular, in 3GPP or 3GPP2 networks, there is no concept of using the civic address information in any way for the positioning purpose.